home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ 2⁄23⁄90 / 0708-Re Error Check w⁄o d-Feb90 < prev    next >
Encoding:
Text File  |  1990-02-23  |  1.7 KB  |  45 lines  |  [TEXT/GEOL]
  1. Item forwarded  by  A33          to A34
  2.  
  3. Item    0772933                         18-Feb-90        15:37PST
  4.  
  5. From:   MADA2                           MacApp Dev Assoc, Curtis Faith,IVC
  6.  
  7. To:     FRIEDRICH1                      Friedrich, Steve
  8.  
  9. cc:     MACAPP.TECH$                    MacApp Technical
  10.  
  11. Sub:    RE Error Check w/o debugger
  12.  
  13. Steve and Steve,
  14.  
  15. I would like to second the request for a separation of error-checking (focus
  16. assertions, TList range checking etc.) from the MacApp debugger.
  17.  
  18. I think that this would be very valuable for those who are blowing the jump
  19. table with debugging on.
  20.  
  21. I also strongly suspect that the future users of Think Pascal, (and Steve's
  22. Debugger) would benefit greatly from not always needing the entire debugging
  23. environment to do error assertions.
  24.  
  25. The implementation of messages without a debug window could be handled through
  26. a call to a method of TApplication.  The default might be to Writeln the
  27. message to the Debug window if debugging is on and bring up an alert if it is
  28. off.  One could OVERRIDE this for any alternative behavior, like special calls
  29. to The Debugger or Think Pascal (I am hoping for some sort of Think equivalent
  30. to DebugStr ).  However you handle it, it would be nice to have the calls go
  31. through a method.  I really like to mess around with these sorts of things.
  32.  
  33. The MacApp debugger is an excellent way to quickly nail down certain types of
  34. errors.  It is not always available due to Jump table limits.  I think the
  35. separation would greatly benefit MacApp.
  36.  
  37. I don't seriously expect to see this in 2.0 final, but what about 2.1 or
  38. perhaps the Ninja MacApp 2.0.
  39.  
  40. - Curtis
  41.  
  42. P.S. I am really looking forward to working with 2.0 final.  It looks likeyou
  43. have, once again, put in some neat additions!
  44.  
  45.